N94-21332 

SPACE NETWORK SCHEDULING BENCHMARK: 

A PROOF-OF-CONCEPT PROCESS FOR TECHNOLOGY TRANSFER 


Karen Moe 

NASA/Goddard Space Fit. Center 
Code 522 

Greenbelt, MD 20771 
(301)286-5998, FAX (301) 286-1768 

B J Hayden 

NASA/Goddard Space Fit. Center 
Code 534 

Greenbelt, MD 2077 1 
(301)286-7307, FAX (301) 286-791 1 


Nadine Happell 

Stanford Telecommunications 

1761 Business Center Dr. 

Reston, VA 22090 

(703)438-8028, FAX (703) 438-81 12 
Cathy Barclay 

AlliedSignal Tech. Service Corp. 

7515 Mission Drive 
Lanham, MD 20706 
(301) 805-3221, FAX (301) 805-3228 


Summary 

This paper describes a detailed proof-of-concept activity to evaluate flexible scheduling 
technology as implemented in the Request Oriented Scheduling Engine (ROSE) and applied to 
Space Network (SN) scheduling. The criteria developed for an operational evaluation of a 
reusable scheduling system is addressed, including a methodology to prove that the proposed 
system performs at least as well as the current system in function and performance. The 
improvement of the new technology must be demonstrated and evaluated against the cost of 
making changes. Finally, there is a need to show significant improvement in SN operational 
procedures. Successful completion of a proof-of-concept would eventually lead to an 
operational concept and implementation transition plan, which is outside the scope of this paper. 
However, a high-fidelity benchmark using actual SN scheduling requests has been designed to 
test the ROSE scheduling tool. The benchmark evaluation methodology, scheduling data, and 
preliminary results are described. 


Background 

The concept of flexible scheduling has been proposed to help meet the Space Network’s (SN) 
anticipated increase in mission support in the late 1990’s. The goal of flexible scheduling, which 
is described in the next section, is increased resources utilization with less manual effort. If SN 
utilization could be increased 10%, about an additional three service hours per day would be 
available on each TDRS single access (SA) antenna. This increase provides a total of 24 extra 
service hours per day, given four operational TDRSs. Scheduling studies have indicated that the 
flexible scheduling approach will result in increased utilization even if only some customers 
specify flexibility. 1 Furthermore, designers of many upcoming missions have indicated a desire 
to utilize flexible scheduling concepts with the SN. 2 Another benefit of flexible scheduling is 
the reduction in effort required for both customer and Network Control Center (NCC) scheduling 
operator. 3 For these reasons, the Networks and Data Systems Technology Divisions undertook 
a detailed proof-of-concept activity to evaluate the flexible scheduling technology as 
implemented in the Request Oriented Scheduling Engine (ROSE). 4 

A high-fidelity benchmark has been designed to test the ROSE scheduling tool. This benchmark 
uses real SN scheduling requests and then modifies them into flexible requests for those customers 
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who can take advantage of flexibility. The benchmark evaluation methodology and scheduling data 
are described, as well as how the ROSE tool was tailored and used in the proof-of-concept required 
by NCC operations. ROSE is a generic scheduling engine and was augmented by the development 
of two algorithms designed for NCC-type operations, including the lookahead algorithm currently 
in use in the NCC. Also, a usability test has been defined to specifically test the scheduling system 
user interface for supporting NCC operational scenarios. Preliminary results of the benchmark 
functional performance testing are presented. 

Flexible Scheduling Request (FSR) Concept 

The FSR concept is a candidate for the future Mission Operations Center (MOC) interface to the 
SN. The concept has evolved over the years based on experience in mission operations in 
scheduling both spacecraft activities and shared space network services. 5 - 6 > 7 - 8 The flexible 
request approach represents a major change in operations concept. Today each customer submits 
(and resubmits) requests for specific TDRS resources and receives yes/no responses. A large 
percentage of the rejected requests in the current system are resolved by exercising the users' 
flexibility through manual coordination. 9 Alternatively, requirements for space network service 
requests can be specified in an FSR featuring: 

• Flexibility - variable start times, duration, or optional resources 

• Repeatability - number of service repetitions and their periods 

• Alternatives - primary and backup services 

• Constraints - orbital events such as orbits, TDRS antenna view periods, spacecraft day, 
equator crossings, etc., relationships with other services or requests, or calendar events. 

In flexible request scheduling, the user considers all service options and codifies flexible service 
windows in the request. The space network scheduling system then has more information upon 
which to base scheduling decisions, increasing the likelihood of successfully satisfying the 
request. The format for this new scheduling information may be an extension of the Schedule 
Add Request (SAR) or a new language-based interface. 

A key benefit of the FSR concept is the shift of a significant conflict resolution effort from 
humans to computers. The FSR operations concept minimizes request-response iterations 
between the network scheduling system and the customer since multiple events can be scheduled 
from a single request (using repeatability specifications). Also, backup events can be identified 
and substituted in cases where the primary service is unavailable. The FSR concept supports 
automated conflict resolution strategies, since tolerances in start times and duration are provided. 
More events are scheduled, supporting more effective resource utilization. The time to generate 
a week's worth of schedules can be reduced to hours instead of days. 
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Proof-of-Concept Evaluation Criteria 

For NCC Operations, the goal is for a scheduling tool with built-in flexibility to support an evolving 
and diverse mission support load without increasing operational complexity and cost. The ROSE 
scheduling tool is proposed as such a tool. NCC Operations developed a high-fidelity benchmark 
as a criteria against which to evaluate the scheduling tool. This benchmark must prove that the 
ROSE scheduling tool performs at least as well as the current scheduling system while providing a 
significant improvement in SN operational procedures. The SN schedule produced by ROSE must 
be at least as good in terms of fulfilling customer requests as that produced by the current system. 

In addition, the process by which the final schedule is produced must show a measurable 
improvement over the current process, including processing time. The human intervention required 
by the current process is predicted to be the true bottleneck in scheduling customers in the late 
1990's time frame. Therefore, the most important evaluation criteria for a new scheduling tool is 
the improvement that it can provide to the overall scheduling process in reducing the time 
consuming human interchanges. 

Since NCC Operations will emphasize the scheduling process improvement in evaluating any new 
scheduling tool, the criteria against which ROSE will be measured consists of computer processing 
time and manual intervention involved in the total scheduling process. The analysis must go 
beyond a comparison of computer processing time for a single schedule period based on priority 
processing. It must be inclusive of the human and computer interfaces between the scheduling 
personnel at the NCC and those at each customer scheduling facility. The benchmark effort has 
been, and will continue to be, an effort to determine these measurements. 

ROSE Benchmark Proof-of-Concept 

The approach for the proof-of-concept involves two phases. In the first phase, the goals are to: 

• Perform a high level assessment of ROSE forecast scheduling ability compared to the 
Network Control Center Data System (NCCDS) 

• Verify that ROSE allocates resource appropriately, and 

• Compare the computer run times required to generate a forecast schedule prior to 
manual conflict resolution. 

Although the NCC scheduling functions involve additional capabilities, (e.g. request validation, 
schedule dissemination) resource allocation is the primary function and clearly the most complex. 
Therefore, our efforts focus on that capability. The resource allocation verification in conjunction 
with the ROSE usability testing will provide the basis for evaluation of ROSE as a scheduling tool 
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from an NCC perspective. This phase will be referred to as "Phase I: Schedule Comparison and 
Resource Allocation Verification." 

In the second phase, the emphasis is on demonstrating improvements in operational procedures and 
evaluating ROSE from a SN customer perspective. ROSE has potential for significantly reducing 
the time required to perform the current NCC forecast schedule generation process because of its 
support of flexibility. This benefits both NCC and customer operations. In this phase we will 
quantify the reduction. Also, since ROSE capabilities involve much greater degrees of flexibility 
than the current NCC, it is important that the customer understand how they can effectively use 
these new flexibility options. The customers' evaluation of the resulting schedule is key to the 
overall assessment of ROSE. This phase will be referred to as "Phase II: Procedure Improvement 
and Flexibility Analysis." 

For Phase I we describe the process, the environment in which the process was performed, the 
schedule and related data utilized, and finally summarize preliminary results. Space doesn't allow a 
similar description of Phase II, however we will highlight the new features and indicate status. 

PHASE I - Schedule Comparison and Resource Allocation Verification 

The Process . The key drivers for devising the resource allocation verification process are time and 
realism. Our goal is to perform a high level comparison of schedules and computer run times, as 
well as to check that ROSE schedules SN resources without conflict. An in-depth detailed 
verification would take on the order of several months and require skilled test personnel. This type 
of testing will be performed in more formal testing phases if ROSE is selected as an NCC 
scheduling system. Realism is key because we want to focus the evaluation on the most common 
types of resource conflicts encountered, while still ensuring all resources are allocated properly. 

The data flow for the Phase I process is illustrated in Figure 1. Shaded boxes indicate completed 
activities at the time of publication. 

Both drivers can be addressed by using operational SARs and related data for an NCC forecast 
week and submitting them to both the NCCDS and to ROSE. The resulting schedules will be 
compared in terms of number of events scheduled and minutes of support scheduled. Currently, the 
operational SARs express flexibility in event start time and SA antenna, therefore, it is possible to 
generate different conflict-free schedules. However, one schedule may better satisfy the SN 
customers. 

While this comparison provides a foundation for evaluating schedules and run times, an additional 
step is required to verify ROSE resource allocation. The ROSE scheduled events will be formatted 
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Figure 1 . Phase I Process Overview 

into specific SARs, without start time flexibility, and submitted back to the NCCDS. Another 
NCCDS forecast schedule generation run will be performed to determine if ROSE scheduled any 
requests in conflict based on NCCDS resource allocation rules. 

The Environment . Utilizing actual SARs requires that the entire process be performed in a 
classified environment. The NCCDS baseline schedule and the resource allocation verification 
schedule run will be performed within the NCC. A SUN Sparcstation will be installed in the NCC 
to support the ROSE benchmark evaluation effort. The results of the evaluation will be presented in 
an unclassified manner. 

To provide an accurate comparison of the NCCDS baseline schedule and the ROSE generated 
schedule, the comparison is made for running all SARs together in one schedule generation run. 

The NCCDS baseline schedule prior to any manual conflict resolution is the result of that run. 

In the NCCDS, the resources utilized in the schedule run are dependent on the ground terminal that 
supports the available TDRSs. Since the time frame in which a new NCC scheduling system would 
be implemented is likely to be after the Second TDRS Ground Terminal (STGT) is operational, all 
TDRSs will be assigned to STGT for all of the Phase I schedule runs. 
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Schedule and Related Data Collection 


It was necessary to carefully choose and coordinate the SARs, configuration codes, prototype 
events, and spacecraft priority list for all of the tests. To obtain the operational SARs, a forecast 
week was selected that included a shuttle mission to address a significant scheduling workload. 
Coordination with the SN customers was necessary in gathering mission scheduling data. The 
SARs were logged by the NCCDS Test System (NTS) for the test. Compatibility tests were 
performed between the NTS and ROSE to ensure that they could reliably exchange the SAR data. 
The NTS will be used to extract the SARs and to submit the ROSE generated SARs to the NCCDS 
for the resource allocation verification step. 

Configuration codes and prototype events are specified in the SARs. Copies of these were provided 
to ROSE to ensure that the same resources are requested in all schedule runs. The same spacecraft 
priority list will also be used in all schedule runs in accordance with operational procedures. The 
same NCCDS database which contains the configuration codes, prototype events, and spacecraft 
priority list will be used for the NCCDS schedule run to verify ROSE resource allocation. The 
NCCDS baseline schedule was generated using this database, after all validated SARs were 
received for the selected forecast week. 

The boundary between the active and forecast period was also addressed. Some of the active period 
events start late in the day on the last day of the active period and overlap into the forecast period. 
These events were included in the forecast period schedule data collected for the tests. 

Data Preparation for Input into ROSE 

The first challenge from the ROSE perspective was deciding how to represent NCC information in 
ROSE's Flexible Envelope Request Notation (FERN). ^ This information falls into the following 
general categories: resources for allocation, scheduling ground rules, and requests. Scheduling 
ground rules include specifications for setup buffers on resources (i.e., the time required between 
uses of a resource), duty factors on the Multiplexer/Ddemultiplexer (MDM) and Statistical 
Multiplexer (Stat Mux), and restrictions on the choice of TDRS antenna within an event. 

Scheduling Resources . In order to schedule the SN, both communication services and TDRS 
antennas must be allocated, although there is a very strong tie between them. For Multiple Access 
(MA) services, one service equates to one antenna. However, multiple SA services may be 
scheduled on a single physical antenna, provided all services are for the same customer (since the 
antenna can point to only one spacecraft at a time). Customers request services. However, once 
one SA service is assigned to a customer, the remaining SA services on that antenna can not be 
assigned to any other customer. Therefore in requesting an SA service, the customer is in effect 
requesting an SA antenna. However, due to equipment failures, not all SA antennas support all 
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services. The NCC maintains equipment status, and therefore must insure that a customer is 
assigned to an SA antenna capable of supporting the services requested. 

The definition of the resources within ROSE accounts for this close coupling of two different 
resource types (antennas and services). To do so, the physical antennas were defined as the most 
primitive resources. Each service was then defined as a pool of physical antennas capable of 
supporting that service. In order to insure that all SA services for an event were assigned to the 
same SA antenna, combinations of services were defined as resources that list all of the physical 
antennas capable of supporting all services in that combination. The customer then specifies a 
service combination as a requested resource. ROSE assigns the event to a physical antenna listed in 
the service combination definition. This physical antenna is no longer available to other requests 
for the time frame requested. However, this strategy does allow multiple services from the same 
request to be assigned to the same physical antenna. 

Other resources, such as interface channels and duty factors, are more independent and made a 
fairly simple transition into FERN and ROSE. Requests for certain customer interface channels do 
imply a need to request certain duty factors, however this relationship impacts the original request 
generation and not the scheduling process. Interface channels are simple capacity resources; 
customers request a single unit of each interface channel and they are either available or not. Duty 
factors are consumable/renewable resources, where customers request multiple units corresponding 
to their required maximum bandwidth. The combined bandwidth of all services from all customers 
cannot exceed a certain threshold. 

Scheduling Ground Rules . The majority of the scheduling ground rules were worked into the 
resource definitions. The duty factor constraints were implemented as consumable/renewable 
resources as mentioned above. Resource setup buffers specify the amount of time required between 
each use of a resource for reconfiguration for the next support. The SN uses two setup buffers for 
many resources, one where the next use of the resource is in another event (external buffer), and 
one within the same event (internal buffer). FERN has an option within the resource definition for 
specifying a minimum gap between each use of the resource, but is incapable of expressing internal 
event buffers. Since all external buffers are equal to or slightly larger than setup buffers internal to 
an event, only the external buffers were implemented. Not using internal buffers was insignificant 
to the benchmark, since the likelihood of an event containing back-to-back use of a resource within 
the internal buffer is improbable, given the experience of current SN customers. 

There are additional ground rules that specify that all services within an event must be on the same 
TDRS, and that if a service stops and restarts within an event, the same antenna shall be used for 
each instance of the service. These restrictions were incorporated into the scheduling algorithm. 
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The NCC Lookahead Algorithm . The NCC lookahead algorithm uses a conflict avoidance strategy. 
The basic principle is to examine the placement options of an event, and schedule it in the spot that 
is least likely to create a conflict with a lower priority pending request. Figure 2 illustrates the logic 
flow as implemented in ROSE. 


Begin 



Figure 2. Lookahead Algorithm Logic as Implemented in ROSE 

The lookahead algorithm implemented in ROSE, has some subtle differences with the NCCDS 
implementation. The NCCDS version looks for potential conflicts across services; the ROSE 
version looks for them across physical antennas. It was determined that this difference would have 
no impact on schedule outcome. The NCCDS version selects the best location for an event based 
on the combined potential for conflict across all services in the event. The ROSE version selects 
the best location for each activity (or service) individually. In flexible requests, it is possible to 
have more than one activity per event, therefore the best location for the event is not guaranteed. 
However, for Phase I, where the requests are relatively inflexible, there is a one-to-one 
correspondence between activities and events and no impact should be seen. 

Other differences occur in the minute details of the implementation. These include differences in 
step size when sliding the start time around within an open window, and differences in the size of 
the weighting factors in computing a conflict sum for each start time and resource option. In both 
implementations, potential conflicts with the next highest priority request are weighted more 
heavily than potential conflicts with the very lowest priority request. Also, potential conflicts on 
resources that are in higher demand are weighted more heavily than potential conflicts on 
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infrequently used resources. The ROSE implementation took advantage of a ROSE feature that 
calculates current resource utilization, so that the resource weights can be adjusted dynamically. 

Requests . The SN services are grouped as an event in a SAR. However, FERN structures its 
requests hierarchically, as shown in Figure 3. The generic structure specifies repetition instructions, 
the activity specifies a sequence of steps and the duration of each step, and the step specifies the 
resources that are required for that period. 



Figure 3. FERN Structure 


Steps within an activity are strictly sequential, whereas SN services specified in a SAR typically 
overlap. Current NCC SARs require the start time of all services to be fixed with respect to one 
another. This restriction allows the time slicing of the event when converting to FERN. Whenever 
a service either starts or stops, a new step is defined. Steps then list all resources required for all of 
the services that are ongoing at that time. For example, an event composed of SS AF, SSAR, and 
Tracking services, would be represented by an activity with four steps as shown in Figure 4. SA 
services are time sliced within the activity, however, they always follow the same order (i.e., 
forward, return, tracking). Thus the combination of FERN activities and steps represent current SN 
events with services being time sliced among the steps. 
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SSAF 


SSAR 


Tracking 


Step: Step 1 Step 2 Step 3 ste P 4 

Services: SSAF SSAF SSAF SSAF 

SSAR SSAR SSAR 

Tracking 

Figure 4. Time Sliced Event Represented in FERN 

SAR Input Translator . A SAR translator, was written in the Unix interpreted language AWK. This 
translator reads in the SAR and reformats it into FERN using the time slicing methodology. Since 
current SARs are non-repeating, the FERN requests will also be unique, with one generic composed 
of one activity for each SAR. Each generic and activity is labeled by customer and SAR message 
id. Each step name lists the customer, message id, and all configuration codes supported during 
that step. Another FERN structure called an annotation, describes each configuration code. The 
information in the annotation is not used by the scheduling logic, but only by the display system. 
Annotations permit services to be displayed as a whole, and not time sliced into multiple steps. 

The configuration codes specified in the SAR contain important information concerning requested 
resources. Since configuration code definitions are in the NCC database, a configuration code 
database was built for the SAR translator. The SAR translator database is significantly smaller than 
the NCC configuration code database since it includes only that information required to support 
resource allocation and only contains those configuration codes actually used during the test week. 
The SAR translator also references the list of the mission priorities. These are the default priorities 
inserted into the FERN requests. However, some users had several critical requests that were given 
a higher priority. These request priorities will be manually modified in the FERN requests. After 
all SARs are run through the SAR input translator, separate FERN request files will be created for 
each customer. The only other file needed for the Phase I test is the file describing the SN 
resources to be allocated. A schedule can then be run using the lookahead algorithm. 

SAR Output Translator . The ROSE output schedule is to be submitted back to the NCCDS to 
verify that ROSE does not inappropriately schedule any requests. The ROSE output schedule must 
be translated back into the SAR format. Another translator has been developed for this purpose. 
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The resulting SARs should express no flexibility at all, since they represent scheduled events 
assigned to specific resources. However, the SAR format does not directly express all required 
resources; some resources are specified in the configuration codes. The SAR output translator 
determines the configuration codes used by each event and references them in the output SAR. 
Unfortunately, most configuration code definitions express flexibility in the antenna choices. If the 
NCCDS were to choose a different antenna than what ROSE actually chose, the change in one 
event could cause a ripple effect and produce a different schedule. However, it appears that the 
NCCDS allocates antennas in numerical order. The resources in FERN can be listed in a similar 
manner, so that the search pattern in both systems should be the same, and result in the same 
assignments. If this strategy fails, however, new configuration codes must be defined with very 
specific resources, and the SAR output translator can be set to reference these new codes. 

Phase I Preliminary Results and Status 

As of October 1, 1993, we have completed the NCCDS baseline schedule and the description of the 
result follows. The ROSE schedule is expected to be run later in October after the host workstation 
is completely installed and procedures are completed for handling classified data. 

The forecast week selected was September 13-19, 1993 (256/00:00:00 - 262/23:59:59 Z). The 
seven day operational forecast process for this week took place beginning on August 30, 1993. We 
extracted the SARs on August 3 1 and performed the NCCDS baseline schedule run on September 
1st. The NCCDS baseline schedule run included 1028 unclassified SARs and took just over 45 
minutes to complete. We measured the primary and secondary resource scheduling separately. 
Primary resources are the SA and MA Forward (MAF), and start time tolerances are used to 
schedule these resources. The STGT era secondary resources used in this schedule run were the 
MA Return (MAR), customer interface channel, MDM bandwidth, and Stat Mux bandwidth. 

Table 1 summarizes the initial result of the NCCDS schedule run for the unclassified customers on 
STGT by order of spacecraft priority before any conflict resolution was applied. The declined 
SARs were due to conflicts on the following resources: 

90% - SA or MAF Conflict 
10% - MAR Limitation 

<1% - User Interface Channel Conflict (one HST request declined) 

The set of declined SARs attributable to the MAR limitation are due to the difference between 
WSGT and STGT resources. TDRS spare was assigned to the third equipment set at STGT 
which does not support MA, hence, SARs for TDRS Spare MAR were declined. Therefore, in 
actuality nearly all the SARs were declined due to SA or MAF conflict. The results indicate that 
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lower priority customers who specify tolerances in their requests, like COBE, do increase the 
likelihood of getting their requests scheduled. 


SN 

Customer 

% SARs 
w/Tolerance 

SA 

Flexibility 

% SARs 
Scheduled 

% SARs 
Declined 

GRO Critical 

0 

Yes 

100 

0 

UARS Critical 

0 

Yes 

100 

0 

STS - 51 

0 

No 

99 

1 

HST 

< 1 

Yes 

64 

36 

GRO 

0 

Yes 

74 

26 

TOPEX 

92 

Yes 

67 

33 

EUVE 

99 

Yes 

66 

34 

UARS 

95 

Yes 

55 

45 

COBE 

70 

Yes 

89 

11 

ERBS 

99 

Yes 

54 

46 

Total 



79 

21 


Table 1. NCCDS Forecast Baseline Schedule Statistics Prior to Conflict Resolution 
The NCCDS baseline schedule also had the following computer run time statistics (mm:ss): 


Primary SN resources: 

03:06 

Secondary SN resources: 

42:11 

Total: 

45:17 


Similar statistics will be generated for ROSE under Phase I testing in October. Upon 
completion, we will compare the NCCDS and ROSE schedules and computer run times, and 
verify that ROSE did not schedule any conflicts. Finally, we will analyze the remaining SARs 
from NCCDS which were not resolved during the manual conflict resolution process, and any 
SARs from ROSE which do not get scheduled. 

PHASE II - Procedure Improvement and Flexibility Analysis 

The Process . As in Phase I, key drivers for devising the process for procedure improvement 
involve time and realism, so again we will compare NCCDS and ROSE schedule runs using 
operational SARs and compare the number of events/minutes scheduled and the computer run 
times. The configuration codes, prototype events and the spacecraft priority list used in Phase II 
will be the same as that used in Phase I. However, in this phase we will also compare the times to 
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perform the entire procedure to create a forecast schedule including conflict resolution. Figure 5 
illustrates the Phase II process. 
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Figure 5. Phase II Process Overview 


The NCCDS baseline schedule run for Phase II was performed by the operations personnel. The 
week selected is the same week as that used in Phase I. When coordinating with each customer for 
Phase I, we also requested that each customer save the scheduling data used to generate their SARs 
for support of Phase II. In addition, operational schedule run data, observation notes, and conflict 
resolution notes were saved. This data will be used to analyze the additional types of flexibility 
available to the customer. 


The additional types of flexibility will be specified as Flexible Scheduling Requests (FSRs) in the 
FERN language. ROSE will utilize the FSRs to generate a forecast schedule that will be compared 
to the NCCDS operational schedule run on WSGT resources. At first, it may seem inappropriate to 
compare an NCCDS schedule run on WSGT resources to a ROSE schedule run on STGT resources. 
However, it turns out the differences between the resources have minimal effect on the computer 
and procedure run times. As for the customer perspective, we expect the differences in WSGT and 
STGT resources to have minimal effect on the use of flexibility. Of course, the difference in 
resources will be considered when comparing NCCDS and ROSE schedules in terms of number of 
events and minutes of support scheduled. Finally, ROSE will again generate specific SARs that 
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correspond to the events scheduled using the FSRs. The specific SARs will be scheduled using the 
NCCDS to provide additional resource allocation verification as with Phase I. The physical 
environment is the same as Phase I. 

User Scheduling Data Collection 

In order to translate the original SARs into flexible requests, we need to understand the customers' 
true flexibility options. We need to understand how they chose where to schedule the requests 
initially, and how they chose what conflict resolution options were acceptable to them, and which 
options were preferred over others. We also need to collect any data, such as user antenna views 
(UAVs), that they may have used in making those decisions. We felt that this data should be 
collected as soon after the test week as possible, so that the activities were still fresh in the 
customers' minds, and that files and tapes were not overwritten or deleted. 

For this data collection process, we visited all of the GSFC Mission Operations Center (MOCs) and 
interviewed their scheduling personnel. We also requested that they complete a short questionnaire 
concerning the conflicts they encountered during the test week, and how they were resolved. By 
personally visiting each customer, we were able to gain a very clear and detailed understanding of 
the customer's side of the process for the test week, as well as collect the scheduling aids (e.g., view 
period data). 

The types of flexibility that different customers may have that cannot be expressed in the current 
SAR are the ability to accept: 

• Shorter service duration 

• Any TDRS as long as it is in view 

• Service start time tolerance 

• Wider event start time tolerance 

• Different type of service (MA vs SA) 

• Moving the contact to another orbit 

• Periodically repeating an event 

One of the key flexibility concepts is SA service start time tolerance with respect to MA services 
within same the event. A previous study showed that 71% to 79% of Hubble Space Telescope's 
conflicts could be resolved using this type of flexibility. 11 The time sliced event representation 
strategy discussed under Phase I allows flexibility in the relative start times of the different services. 

Preparing the FSRs . For Phase II, the request representation we settled on was to have one activity 
for each physical TDRS antenna requested (versus one activity for each event in Phase I). The 
generic data structure allows conjunctions of activities, therefore one generic would specify that the 
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activities in an event must all be scheduled as a unit on the same TDRS. This representation 
strategy allows flexibility in the relative start times of the different activities. 

Most FSRs will be generated manually based on an interpretation of the data collected from the 
MOCs. For most customers this effort is not expected to be excessive, since they can use the 
repeatability factor of flexible scheduling, and one FSR can replace many SARs. For those 
customers who would not use flexible scheduling, the SAR translator can regenerate their specific 
requests. The SAR translator will likely be modified to also support flexible non-recurring 
requests. After the FSRs have been created, the customers will verify that they represent acceptable 
conflict resolution options in the correct order of preference. 

Phase II Preliminary Results and Status 

The NCCDS operational schedule with WSGT resources and including manual conflict resolution 
was completed during the forecast week of August 30, 1993, and the results were collected. The 
number of events at the end of the operational NCCDS schedule run was higher than at the 
beginning of the week for the initial forecast schedule. This discrepancy is due to additional (late) 
SAR submissions during the forecast week, and conflict resolutions that include splitting one event 
into two. 

Based on the customer interviews, there were no resolution options exercised that week that could 
not be expressed in an FSR. Some requests simply could not be satisfied as there were no 
acceptable resolution options. We are optimistic that ROSE will be able to find conflict resolution 
options for all requests that were eventually scheduled. The MOCs will also be asked to judge if 
the options that ROSE found were as good (or maybe even better) than those found manually. We 
hope to be able to estimate the number of staff hours saved by using flexible scheduling over 
manual conflict resolution. Table 2 shows the results for the operational schedule after conflict 
resolution. The column entitled "% Increase over Baseline" shows the additional percentages of 
requests scheduled over the first run of the forecast schedule before any manual conflict resolution 
was completed. 

Generation of the NCCDS operational schedule had the following computer run times (mm:ss): 
Primary SN resources: 06:30 

Secondary SN resources: 1 18:30 

Total: 125:00 

In addition, 60 hours of forecast schedule operator support time (including wait time for MOC 
responses to recommended resolutions) were allocated to the manual conflict resolution procedures 
for the week. The NCCDS preliminary results from Phase II, as compared to the baseline schedule, 

illustrate the significant increases in scheduled support due to the manual efforts of the forecast 
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operators and customer scheduling personnel. The goal of the flexible scheduling concept is to 
automate conflict resolution in the schedule run. Similar data will be collected for ROSE during 
Phase II testing. 


SN 

Customer 

% SARs 
w/Tolerance 

SA 

Flexibility 

°/o SARs 
Scheduled 

% Increase 
over Baseline 

GRO Critical 

0 

Yes 

100 

0 

UARS Critical 

0 

Yes 

100 

0 

STS - 51 

0 

No 

100 

1 

HST 

< 1 

Yes 

99 

35 

GRO 

0 

Yes 

94 

20 

TOPEX 

92 

Yes 

100 

33 

EUVE 

99 

Yes 

98 

32 

UARS 

95 

Yes 

91 

36 

COBE 

70 

Yes 

99 

10 

ERBS 

99 

Yes 

86 ! 

22 

Total 



97 

18 


Table 2. NCCDS Operational Forecast Schedule Statistics After Conflict Resolution 

Lessons Learned to Date 

The ROSE evaluation exercise began in May 1993, and in a relatively short time frame we have 
established a methodology and collected necessary test data for both phases of testing. This same 
methodology could be adapted to similar technology evaluations by other operational systems or by 
the NCC for other proposed enhancements. 

It was necessary to coordinate the collection of data both in the NCC and the MOCs for the selected 
forecast scheduling week. The evaluation team held regular status meetings and established close 
contacts with scheduling and database operations personnel which had several benefits. Many 
detailed but critical points were uncovered and resolved during the process. Everyone maintained 
an eye on the evaluation goals and stayed well informed. Close cooperation was needed between 
government and contractor personnel, as well as between organizational elements. However an end 
result was the high level of interest in the process and results. 

In the process of understanding the scope of scheduling in the NCC, we learned about subtle details 
of the database with its embedded scheduling ground rules, and the importance of finding an 
appropriate representation for SARs. The initial conversion of the NCCDS database into FERN for 
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ROSE input took about a staff month of effort for both analysis and implementation. Representing 
events as overlapping services had to be carefully addressed in ROSE as there were alternative 
implementation approaches. Once determined, the implementation of the SAR translator was fairly 
straight forward, taking only a couple staff weeks. 

The lookahead algorithm developed for ROSE was based on the NCC lookahead algorithm. 
However, the ROSE algorithm takes into consideration the flexibility options which are not part of 
the NCC algorithm. Further testing and some modifications will be required to fully validate the 
ROSE algorithm, however the tolerances and open selection capabilities in the current SARs have 
been successfully tested. Approximately 9 staff months of effort went into the redesign, Ada 
implementation, and testing of the ROSE algorithm to date. 

As we prepare to actually run the validation benchmark test on ROSE, we anticipate that additional 
testing may be required, in spite of successfully testing individual components of the benchmark. 
However, we feel we have developed a robust methodology that will be able to adapt to the new 
lessons we will leam. 


Conclusions and Future Work 

Technology transfer to operational elements involves the necessity of having to maintain support 
while upgrading to a new way of doing business. The NCC requires a proof-of-concept 
benchmark, such as the one we have described, in order to verify the value of proceeding with 
the time consuming task of transitioning into operations. In addition to the validation of ROSE 
for producing SN schedules, a usability test of the ROSE user interface is also in process. The 
ROSE usability test is designed to verify that the interaction techniques provided by ROSE fully 
support the scheduling tasks performed by scheduling operators. Thus direct evaluation by NCC 
Operations personnel will assess ROSE utility and drive the need for modifications. 

If a new technology proof-of-concept such as ROSE is successfully demonstrated in the testing 
process the next step is to develop a methodology for transition into operations. A complete 
operations concept is required, addressing both the NCC and MOC roles and operational 
procedures in the Flexible Scheduling approach. Since a major change to the NCC requires 
changes of the customer community, representatives of the SN and the MOCs have been 
working on a joint paper, "Space Network Flexible Scheduling Enhancements", to identify 
desired enhancements which will be validated in Phase II. Finally, detailed plans for integration 
of the new technology into the NCC, and plans for formal acceptance testing will be required. 
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